home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / STUTTGART / GRAPHICS / TOOLS / SPRVIEW / !SprView / history < prev    next >
Text File  |  1993-08-17  |  12KB  |  291 lines

  1. // --------------------------------------------------------------------------
  2. // !SPRITEVIEW HISTORY
  3.  
  4. !SpriteView is an application I wrote as an introduction to programming in
  5. the Wimp environment using C++: the (very) partial GNU C++ implementation
  6. written by Thomas Aeby (ported down on 27-Apr-93). I've had to write my own
  7. library of functions but I wouldn't wish *them* on anybody!
  8.  
  9. Any additions/alterations that have come about due to other people's
  10. comments/suggestions have those people's names in brackets next to them. For
  11. example, I started this history file on 28-Jul-93 (Joss Smith).
  12.  
  13. // --------------------------------------------------------------------------
  14. // VERSION: 0.08a 28-Jul-93
  15.  
  16. So far, I've written a lot of code. The application is set up to allow only
  17. one window but is written to provide for more.
  18.  
  19. All info in the program information window is filled in once the application
  20. starts.
  21.  
  22. The windows in which the sprite reside are customized when the sprite is
  23. loaded.
  24.  
  25. Memory for sprites is taken from the RMA since I thought the Wimp might need
  26. to be able to find the data for redraw whether the application is paged in or
  27. not. That may not be the case though...
  28.  
  29. I split up the code last night.
  30.  
  31. SpriteView:
  32.   • can load a sprite into a (correctly sized) window.
  33.       The window has no system area (even no border). To make redrawing
  34.       faster, the icon and the window have transparent background colours.
  35.   • allows the user to drag the window around the screen
  36.       This entails dragging the sprite with select
  37.   • allows the user to resize the window
  38.       This entails dragging the sprite with adjust
  39.   • is riddled with error checking
  40.       I have made the decision that good error reporting is vital. I'm quite
  41.       happy with the set up although it makes the code a lot more cumbersome.
  42.       There are even mechanisms for reporting non-fatal errors and (in fact)
  43.       if a Sprite is not loaded, the application can continue without any
  44.       problems.
  45.  
  46. Problems:
  47.   • drag operations
  48.       As yet they are incomplete; more control is needed over the window and
  49.       which part of the sprite is showing. So far, dragging the window means
  50.       it is brought to the front (and there is no back icon) and resizing it
  51.       leaves it where it is on the window stack. This is caused by the use
  52.       of select and adjust.
  53.   • minimum window size
  54.       The window can be made VERY small and this is not really desirable.
  55.       However, I have to allow sprites of any size so I must make the
  56.       minimum size different for different size sprites, with an upper bound
  57.       for the minimum size.
  58.  
  59. // VERSION: 0.09a 28-Jul-93
  60.  
  61. The drag operations now work as desired. That is we now have:
  62.   • move sprite
  63.       linked to Drag
  64.   • resize sprite
  65.       linked to Alt-Drag
  66.   • scroll sprite (horizontal, vertical, and bi-directional)
  67.       linked to Shift-Drag
  68.       Adjust and left,right Shift Keys dictate the behaviour of the scroll
  69.       
  70. I've also implemented
  71.   • put to back
  72.       linked to DoubleClick
  73.  
  74. I've created a !help file which details all of the behaviour I would like in
  75. the finished product so far.
  76.  
  77. // VERSION: 0.10a 29-Jul-93
  78.  
  79. Fixed bugs, now:
  80.   1) windows open on top.
  81.   2) minimum allowed area depends on sprite
  82.   3) sprites with masks have filled backgrounds
  83.  
  84. Have decided on a policy for having multiple frames on the same sprite. I've
  85. implemented the ideas though have not yet had the courage to allow more than
  86. one window in my compiled code.
  87.  
  88. Got a preliminary sprite menu up and running. The menu contains:
  89.   • New View
  90.      Not yet implemented.
  91.  
  92.   • Lock/Unlock
  93.      Allows you to fix the position of the window and disables all drag
  94.      events. It also ignores any OpenWindow block for locked windows
  95.      and substitutes the status of the window when lock was selected
  96.      but I don't think OpenWindow gets generated so the window drifts
  97.      up and down in the stack. I've allowed DoubleClick to remain.
  98.  
  99.   • Remove
  100.      Works for one Sprite and should work for more.
  101.  
  102. // VERSION: 0.11a 30-Jul-93
  103.  
  104. I have now written the scroll drag operations myself rather than relying on
  105. the Wimp so that the drag looks like the sprite is being moved by the pointer
  106. rather than against it. This has a more intuitive feel.
  107.  
  108. Implemented New View and tested !SpriteView with a maximum of 5 sprite
  109. windows allowed. It worked fine! One problem, though, is that the menu
  110. disappears even if you hold adjust down. It shouldn't but I have a feeling
  111. the sequence of operations I perform in NewView induces this.
  112.  
  113. The new window opens at the bottom left of the screen.
  114.  
  115. Have had one unexplainable crash which happened whilst using a different
  116. application. I don't think I can recreate it but have decided it might be
  117. linked to my use of RMA space directly for my sprites.
  118.  
  119. // VERSION: 0.12a 31-Jul-93
  120.  
  121. I have written all the allocation and deallocation code for my SpriteWindows
  122. myself and no longer use RMA blocks or mallocs. I was just going to use
  123. mallocs but found that no memory was released from the wimpslot once it was
  124. claimed even if I knew my code had freed the pointers.
  125.  
  126. The memory management is now written to use a RISC OS2 style Heap structure
  127. with memory being returned automatically when enough free space presents
  128. itself at the end of the heap. Shifting is not yet performed though adjacent
  129. free blocks are merged.
  130.  
  131. I've included diagnostics which are outputted while the application is
  132. running, into a file called 'DIAGNOSTICS' in the SpriteView directory (if I
  133. set up the code to do so of course).
  134.  
  135. // VERSION: 0.13a 31-Jul-93
  136.  
  137. At last I've got my sprite shifting (Shift-Drag = Scroll Window) to work
  138. properly. The initial direction of the drag dictates which way the window can
  139. move. If Adjust is used to start the drag, the window can be shifted in any
  140. direction.
  141.  
  142. I've taken resizing from the wimp now. You can resize any side/corner and the
  143. picture remains still unless the frame size expands so as to make moving
  144. necessary. Basically, it does the same as the Adjust Size icon but you can
  145. resize in many different ways. Once again, the mouse movement defines the
  146. side (corner if Adjust is used).
  147.  
  148. I've also added a different way of shifting the sprite: the sprite remains
  149. fixed and the window travels over it. I have put checks in to make sure the
  150. window doesn't disappear off the screen but the upper edge check is not quite
  151. right yet.
  152.  
  153. Realized that you can at present resize the window so that it disappears off
  154. the screen but fixed it.
  155.  
  156. Made the pointer disappear while the drags were taking place.
  157.  
  158. // VERSION: 0.14a 2-Aug-93
  159.  
  160. I've increased the number of windows allowed to 30.
  161.  
  162. There were a few bugs in the error trapping concerned with memory allocation
  163. and sprite file loading and so I've got rid of these. I've had to rewrite the
  164. file size check since I wrote it using a standard library function and so the
  165. application crashed when the operation failed.
  166.  
  167. // VERSION: 0.15a 2-Aug-93
  168.  
  169. Implemented the stick function (which involved smartening up the poll loop a
  170. little). This is a nice feature (IMO) so I'll dedicate this version to it!
  171.  
  172. // =========================================================================
  173. // RELEASE 1
  174. // =========================================================================
  175. // VERSION: 0.16 4-Aug-93
  176.  
  177. Reimplemented file loading so that only the first sprite in the file was read
  178. in rather than the whole file (Ian Fry). I've also moved towards allowing
  179. other sprites in files to be loaded without ever having to read in the whole
  180. file.
  181.  
  182. Dropped the 'a' from the version number. They are all alphas so far.
  183.  
  184. Read PageSize instead of assuming it was 32K (Ian Fry).
  185.  
  186. Updated the !Help file to make it acceptable for a release.
  187.  
  188. // VERSION: 0.17 5-Aug-93
  189.  
  190. Added Save box. Doesn't work yet. It also gets picked up as an
  191. Information Window every now and again and gets its Ok box altered.
  192.  
  193. Added File Information Window. Just Ctrl-Drag file onto icon or press Ctrl
  194. while double-clicking on the icon. I've got this window working fairly well
  195. now. It brings up a list of all the sprites in the given file and allows you
  196. to load a sprite in by clicking with Select on the button next to its name.
  197. You can remove the sprite by pressing Adjust on the button or using the
  198. sprite's menu. The only real bug is that error with the Save Box.
  199. (Note: The information is read from the file so no actual sprite
  200. images are held in memory unless displayed).
  201.  
  202. I've rejected idea of putting all data on the sprite list. I'll provide some
  203. means of getting a little Sprite Info window that tells you more about a
  204. particular sprite but I don't want to clutter the screen with a massive
  205. table.
  206.  
  207. Speeded up loading from big files by storing offsets (of sprites into sprite
  208. files) in memory.
  209.  
  210. Found bug in Save box/Info Windows.
  211.  
  212. // VERSION: 0.18 6-Aug-93
  213.  
  214. Fixed the bug with Save box/Info windows.
  215.  
  216. Got the Save box completed. The Save box is a little non-standard since the
  217. leafname is kept seperate from the pathname. I've made it so that the OK
  218. button goes in when the save gets close to working or does actually work
  219. (i.e. an error message should be displayed if the button goes in and the save
  220. fails).
  221.  
  222. // VERSION: 0.19 8-Aug-93
  223.  
  224. Added ability to save from other applications. Decided that allowing Ctrl-Drag
  225. functionality was not really required so only one sprite is loaded and displayed.
  226.  
  227. Started an 'Edit' submenu to allow a few changes to sprites to be made.
  228. So far I have implemented 'Crop' which creates a completely fresh sprite
  229. of the presently viewed section of the current sprite.
  230.  
  231. // VERSION: 0.20 16-Aug-93
  232.  
  233. Added 'Flip X' and 'Flip Y' to the Edit menu and made sure that 'New View's
  234. onto the same sprite were updated instantly.
  235.  
  236. Fixed the readjustments so that resize can allow sprites to be resized
  237. bigger than the screen as long as the picture is still visible.
  238.  
  239. Implemented key shortcuts. So far:
  240.    ^O - open window fully
  241.    ^N - new view
  242.    ^R - remove sprite window
  243.  
  244. Added a submenu to the Remove option on the Sprite Window menu. Now have the
  245. ability to remove the sprite or all copies of that sprite or all sprites
  246. in the application.
  247.  
  248. // =========================================================================
  249. // RELEASE 2
  250. // =========================================================================
  251. // VERSION: 0.21 17-Aug-93
  252.  
  253. Fixed bug in key shortcut code by making it necessary to click in the window
  254. for it to gain the input focus. Added the following key shortcuts:
  255.    ^B          - put to back
  256.    ^C          - Crop sprite
  257.    ^F          - bring to front
  258.    left arrow  - flip x
  259.    right arrow 
  260.    up arrow    - flip y
  261.    down arrow
  262.  
  263. Spotted problem with key shortcuts in that a window can be removed while its menu
  264. is still open.
  265.   
  266. Added ability to grab the contents of a window or an area of the screen though
  267. I'm not yet sure it *always* works yet since I may not be accounting for
  268. wastage properly when claiming enough memory and hence there may still be some
  269. 'Not enough memory to create sprite' errors.
  270.  
  271. // FUTURE PLANS
  272.  
  273. Must rid myself of the ^R bug (closing a window when its menu is open)..
  274.  
  275. I might implement an info box for saying which mode it was defined in  and
  276. its size, for example.
  277.  
  278. May provide multitasking error reporting.
  279.  
  280. May (eventually) cater for sprites with masks properly. Hmmm.
  281.  
  282. Would like to allow other editing facilities on sprites: Magnify,
  283. Rotate. Some would create new sprites others would apply to existing sprite.
  284.  
  285. May have button on Save Box to make sprite name the same as that of the
  286. sprite in the window. (This would only be sensical for original sprites).
  287.  
  288. Gather the sprites on a mode change - at present you can lose them.
  289.  
  290. // --------------------------------------------------------------------------
  291.